============================================================== Guild: wafer.space Community Channel: ℹ️ - Information / general Topic: Welcome to [wafer.space](https://wafer.space/) - documentation at [wafer.space github](https://github.com/wafer-space) - buy at [buy.wafer.space](https://buy.wafer.space) - archives at [discord.wafer.space](https://discord.wafer.space/) After: 2025-07-31 11:59 p.m. Before: 2025-09-01 12:00 a.m. ============================================================== [2025-08-01 11:11 a.m.] tholin I know there was someone who was yearning for a transmission gate in the 5V 7-track SCL. Well, I made it in both _1 and _2 variants. I’m not sure how to characterize these, though. lctime can’t do it. {Attachments} 2025-08_media/image-754CB.png 2025-08_media/image-1BB3A.png {Reactions} 👍 (2) [2025-08-01 11:13 a.m.] tholin I can characterize the delays from A -> Y when the EN = 1, ENB = 0. But I cannot characterize the turn on/off delays when switching the enables. So they’re treated like regular buffers by STA. [2025-08-01 11:14 a.m.] tholin I can also make a version with the inverter to generate ENB built-in, but I believe the idea is that multiple of these can share one inverter. [2025-08-01 11:16 a.m.] tholin I know a multi-bit flip-flop was also a thing that people wanted, so I may do that next. [2025-08-01 11:20 a.m.] tholin I know a 8-to-1 mux was also on the list of desired standard cells. But that one is gonna take some doing. That’s a lot of logic. [2025-08-07 2:36 p.m.] tholin Do we know what actually happens when a 3.3V FET is pushed into punch-through? [2025-08-07 2:36 p.m.] tholin What kinda currents are to be expected? [2025-08-07 2:36 p.m.] tholin Unfortunately, its not included in the SPICE models. [2025-08-10 11:12 a.m.] mole99 I don't think so, at least not on GF180MCU. I assume that this is often not modeled since you are outside the safe operating range. [2025-08-10 11:13 a.m.] mole99 By the way, here are a some nice I/O cell symbols for IHP as inspiration: https://github.com/IHP-GmbH/IHP-Open-PDK/pull/630 [2025-08-10 11:24 a.m.] tholin I also see we don't have a IO pad cell that can switch between analog and digital IO. I wonder how difficult that would be to do. [2025-08-10 11:25 a.m.] tholin The naive approach I feel like taking is it to take the existing digital bi-directional IO cell and cramming a transmission gate in there somewhere to switch an analog signal. [2025-08-10 11:26 a.m.] tholin The digital output can already be fully disabled, of course. [2025-08-10 11:26 a.m.] tholin If that is not the stupidest idea ever, though, I think I can pull that off quite easily. [2025-08-10 11:54 a.m.] 246tnt But ... why ? [2025-08-10 11:55 a.m.] tholin Didn't sky130 have such cells? [2025-08-10 11:55 a.m.] tholin I mean, sky130 caravel [2025-08-10 11:56 a.m.] tholin I remember that being a thing in the IO configuration options in mgmt controller firmware, at least. And option for analog. [2025-08-10 11:56 a.m.] 246tnt It did, but AFAIK no-one was using them and caravel didn't either. [2025-08-10 11:56 a.m.] tholin It would be useful for multi-project dies [2025-08-10 11:56 a.m.] 246tnt The option for in the mgm controller was just disabling the output buffer and input buffer. [2025-08-10 11:57 a.m.] 246tnt The transmissions gates and analog muxing and all the analog stuff of the IO cell was never used. Instead carvel just wired directly to the pad through a resistor, no switching. [2025-08-10 11:57 a.m.] tholin I kindof need such a cell for my own purposes, at least. [2025-08-10 11:58 a.m.] 246tnt And that's what they did in GF too, hence the `ef` IO pad where they just added an analog connection. [2025-08-10 11:58 a.m.] tholin Oh [2025-08-10 11:58 a.m.] tholin Oh so that's what's different about the ef cell [2025-08-10 11:58 a.m.] 246tnt yes [2025-08-10 12:00 p.m.] tholin Just a resistor doesn't seem like the best approach to me, tbh [2025-08-10 12:00 p.m.] tholin Since that does limit current [2025-08-10 12:00 p.m.] 246tnt The resistor is just meant as ESD protection. [2025-08-10 12:03 p.m.] tholin I mean, I'm also worried that if the pin is used for digital IO too, the digital voltages might backflow into the analog circuitry and cause damage, especially if that pin's dual purpose is analog output. [2025-08-10 12:04 p.m.] 246tnt Well it all depends on what's wired to the analog pin of course. There is no "one-size-fit-all". Because a pass gate is a non-linear resistor which is also not a perfect solution. And depending on its size it will also be a current limit ... or an added capacitance depending on where you lie on its size ... [2025-08-10 12:05 p.m.] tholin Right [2025-08-10 12:06 p.m.] tholin I'll have to evaluate that on a case-by-case basis [2025-08-10 12:07 p.m.] tholin Of course, I do hope I'll be able to customize the pad frame and swap out the actual IO pad structures for my own so that I may do that. [2025-08-10 12:15 p.m.] tholin Speaking of the mgmt controller, though: will wafer.space customers have the option of using the RISC-V management controller wrapper on their dies? If so, I have to report a really nasty bug in that thing's caches that I found that caused me a lot of grief and that should definitely be fixed. [2025-08-10 12:20 p.m.] 246tnt The home page specifically states "... not requiring the usage of a specific pad frame or Caravel." [2025-08-10 12:31 p.m.] tholin Well, "not requiring" still does not exclude the possibility of it being an option. [2025-08-10 12:34 p.m.] tholin But basically, user area wishbone writes corrupt the latest data cache entry. So if you set a variable before doing that wishbone write, the variable write has now been undone until the cache is flushed. [2025-08-10 12:34 p.m.] tholin Or...something like that. Its weird and hard to debug. I just have a way of reproducing it sitting in one of my repos somewhere. [2025-08-10 12:53 p.m.] mole99 It would be great if you could file an issue here: https://github.com/fossi-foundation/caravel_mgmt_soc-gf180mcu [2025-08-10 12:58 p.m.] tholin I will! I didn't know there was new repos for this stuff. [2025-08-10 12:58 p.m.] tholin I kinda thought I'd never get to report that bug when efabless went under. [2025-08-10 1:25 p.m.] mole99 Thanks! Yes, the repos under the FOSSi Foundation should be considered the authoritative source. [2025-08-21 4:45 p.m.] mithro_ @Leo Moser (mole99) / @tnt / @Tholin / @psychogenic - Probably a good idea to have the discussion about the padring and chip-on-board stuff here? [2025-08-21 4:46 p.m.] mithro_ @Tholin - It appears that Tiny Tapeout finally convinced @Tim Edwards to join Discord so I invited him here too. [2025-08-21 4:46 p.m.] rtimothyedwards_19428 Yeah, I'm here. : ) {Reactions} 👋 (2) [2025-08-21 4:52 p.m.] 246tnt Well, what I'd like is that for TT users, whatever they receive, they should have the option to use it on a custom board without having a gigantic connector and huge associated parasitics. ATM with a QFN it's easy enough to unsolder it to re-use it and we also sell kits where the QFN is not soldered and thus can be easily used on custom projects. QFN also make testing before full assembly easier because it's easy for me to do one and validate things. For the last 2 (or3?) TT boards, there was something that went wrong and required fixing before final assembly of the whole batch. Bare-dies and wire bonding make all of that not trivial ... [2025-08-21 4:54 p.m.] 246tnt The only 2 ideas I had were : * Use a tiny board-to-connector like they use on cell phones and stuff, something small and hopefull not too expensive but still doesn't have huge parasitics * Make our "homebrew" QFN basically wirebonding the chip to a tiny ( like 15mm x 15mm ) thin PCB that exposes pads on the bottom and can be reflowed on the final PCB. [2025-08-21 4:55 p.m.] mithro_ I updated a few details on chip on board thoughts @ https://docs.google.com/document/d/1ts9o1qC_U_-j65IQ7aDVNUoQ0aruVR_bUW2TsVUjdYo/edit?tab=t.0 {Embed} https://docs.google.com/document/d/1ts9o1qC_U_-j65IQ7aDVNUoQ0aruVR_bUW2TsVUjdYo/edit?tab=t.0 wafer.space - GF180MCU Chip-on-Board (COB) Packaging Goal As wafer.space provides bare die -- the goal is to provide a number of existing pad rings for people which have associated PCBs already designed (with a known cost) and manufacturer pathway (which also has a known cost). As the PCB needs to be designed for a specific pad ring -- design of ... 2025-08_media/AHkbwyL11tj3cvfD7UzevwkoORdeaJ9W8HGrPU1S7w-7E59E [2025-08-21 4:59 p.m.] 246tnt As far as the pad ring, the only thing I would specify is the number and position of pads _if_ you plan to offer more than bare die but also some form of "packaging" service. What the actual pins are doesn't really matter ... With the possible exception of marking some of the sites as being "GND" so you can bond them to a gnd pad or to the substrate via conducive epoxy or such. [2025-08-21 5:01 p.m.] mithro_ I'm working on partnering with PCB Way, Seeed and JLCPCB (talking to people at each of these companies) so they can do the packaging. [2025-08-21 5:01 p.m.] mithro_ I've also been meaning to chase up @stuart about what his partner can / can't do. [2025-08-21 5:02 p.m.] mithro_ I wrote in the document; > As wafer.space provides bare die -- the goal is to provide a number of existing pad rings for people which have associated PCBs already designed (with a known cost) and manufacturer pathway (which also has a known cost). [2025-08-21 5:06 p.m.] mithro_ I created the #📦-cob channel for the chip-on-board discussion. [2025-08-21 5:08 p.m.] tholin Padrings is also another interesting topic, I'd say. [2025-08-21 5:09 p.m.] mithro_ I've see cob and padring stuff connected? [2025-08-21 5:15 p.m.] tholin Alright [2025-08-21 5:23 p.m.] mithro_ People might find https://bit.ly/ws-tiny-riscv-proof interesting too. {Embed} https://bit.ly/ws-tiny-riscv-proof wafer.space - GF180MCU Bit Serial RISC-V Implementation - bit.ly/ws... GF180MCU Bit Serial RISC-V Implementation https://bit.ly/ws-tiny-riscv-proof Goal The primary goal of this project is to show a potential pathway to creating “custom RISC-V” chips with wafer.space’s low volume manufacturing & chip on board packaging that are within the realm of being cost compet... 2025-08_media/AHkbwyLB4cIdHr5BaevGBccwKPL1xmYlo7H4OScvtA-F2458 {Reactions} 👍 [2025-08-21 5:31 p.m.] 246tnt Not really sure why you want to go bit serial ... the size of the SRAM is going to be way bigger than the rest of the logic I think. [2025-08-21 5:31 p.m.] 246tnt Also if you have the full die for it, then space is really not much of a constraint. [2025-08-21 5:31 p.m.] urish unless you want a 64-core MCU 😉 [2025-08-21 5:44 p.m.] mithro_ @tnt - The idea is to sub-divide the die into even smaller die to get cost down even further [2025-08-21 5:45 p.m.] mithro_ IE Try to prove you could do a sub-$1 type thing. [2025-08-21 5:46 p.m.] 246tnt So you're going to have different die sizes ? [2025-08-21 5:51 p.m.] saladchap Place I know only does alu wire bonds, not gold. They can do packaging too but not asked for details, do we have any kind of spec or requirements data I can share with them? [2025-08-21 5:52 p.m.] mithro_ @digshadow Was looking at dicing the bare die even further with lasers and similar [2025-08-21 7:38 p.m.] digshadow yeah and I would go so far to say I'll probably laser dice the "garage semiconductor" test chips at some point [2025-08-21 8:02 p.m.] mithro_ Started a thread. [2025-08-21 8:03 p.m.] mithro_ I'm clueless enough to not know why alu matters verse gold? [2025-08-22 6:27 a.m.] mole99 So do we ditch Caravel and its padframe? As @Tim Edwards mentioned in FOSSi Chat, it's excruciatingly slower than the earlier picorv32 implementation (about 100 times slower), and as @Tholin discovered, there's a major bug in it (https://github.com/fossi-foundation/caravel_mgmt_soc-gf180mcu/issues/1). If @tnt uses the same script to create the I/O cell positions as for Tiny Tapeout on IHP, this would be compatible with the LibreLane padring generation step. I can then replicate the same padring using just the config.yaml in LibreLane, and wafer.space users could easily swap out the I/O cells for other types. [2025-08-22 6:31 a.m.] 246tnt I was definitely going to use the same script ... (or possibly just use the one merged in LibreLane if I manage to get it to do what I need). I mean it just distributes the IO as evenly spaced as possible so that satisfies my OCD 😅 [2025-08-22 6:56 a.m.] mole99 Well, an even distribution definitely makes sense :) We just need to think how we can improve the script when we have differently sized cells, or cells with two bondpads. But luckily, the I/O cells in gf180mcu all have the same size again. You would need to enter the I/O cell names and the instances similar to [here](https://github.com/mole99/greyhound-ihp/blob/dd7334364b053c3a0b52e81fc34a8fffb9808f5f/config.yaml#L162). But I think in your script you automatically place the I/O cells based on the instances? In that case, the padring step allows you to supply a custom pad.cfg, similar to the PDN step. [2025-08-22 7:37 a.m.] 246tnt Yeah the instance name is ... randomly picked by yosys with a bunch of `generate so the best I can do is match it with regexp but definitely not provide one complete stable name. And yeah, I don't see why you need to set the pad type in the config. You instanciate them in the verilog right ? So that info is available in the database already and from the name you can get the type. [2025-08-22 7:44 a.m.] mole99 True, that would be a nice improvement! [2025-08-22 7:55 a.m.] tholin I assume all this means I’d have to cook up my own setup for generating the top level GDS and all the macros using LibreLane? [2025-08-22 7:59 a.m.] mole99 What do you mean by that? From now on, you should no longer use OpenLane anyway. There will probably be a wafer.space example design that can be used as a starting point for creating the complete chip with padring. [2025-08-22 8:03 a.m.] tholin I did say LibreLane. Avoiding the old OpenLane is what I’m trying to do, otherwise I’d be a little more okay with using the gf180 caravel_user_project. [2025-08-22 8:09 a.m.] mole99 Yes, I thought it was clear that we are using LibreLane for everything. So I thought your question was about something else, maybe reusing macros from OpenLane - which is possible. [2025-08-22 8:12 a.m.] tholin No, I’m worried about *not* being able to use LibreLane. Don’t wanna fall back to OL. [2025-08-22 8:13 a.m.] mole99 Then it's all fine :) [2025-08-22 9:45 a.m.] mole99 {Attachments} 2025-08_media/Bildschirmfoto_vom_2025-08-22_11-35-06-BCD4C.png [2025-08-22 9:45 a.m.] mole99 Not bad for starters [2025-08-22 4:27 p.m.] mithro_ https://ic.onidev.fr/library/gf180mcu.html [2025-08-22 5:37 p.m.] mithro_ If anyone is procrastinating, feel free to update the info @ https://bit.ly/ws-gf180mcu-stdcells 🙂 {Embed} https://bit.ly/ws-gf180mcu-stdcells wafer.space - Notes around voltages and options for I/O and standar... Notes around voltages and options for I/O and standard cells bit.ly/ws-gf180mcu-stdcells Voltages and GF180MCU See also https://bit.ly/ws-gf180 The GF180MCU process uses the same stack as the other 180nm process technologies but changes; The default oxide to be the same as the other 180nm proce... 2025-08_media/AHkbwyIkx20_yVUaPkY6H1IWJgHkZmbxZWsYMNxTFv-53089 [2025-08-22 6:04 p.m.] tholin I added some info [2025-08-22 6:11 p.m.] mithro_ Thanks! I moved your lib closer to the top as one which is under active development. [2025-08-22 6:27 p.m.] mithro_ BTW The LibreSilicon people have a solution called popcorn which "grows" standard cells out of an inverter - https://pdk.libresilicon.com/ {Reactions} ❤️ [2025-08-23 1:52 p.m.] leviathanch. Exactly. We also already generate standard cells for SKY130, GF180 and most recently I have introduced support for IHP's SG13G2 https://gitlab.libresilicon.com/generator-tools/standard-cell-generator {Embed} https://gitlab.libresilicon.com/generator-tools/standard-cell-generator Generator tools / Standard Cell Generator · GitLab GitLab Community Edition 2025-08_media/twitter_card-570ddb06edf56a2312253c5872489-FA048.jpg [2025-08-23 1:52 p.m.] leviathanch. Skywater and IHP's cells still have some short circuits and I'd be glad if some folks could render some support with solving it [2025-08-23 1:53 p.m.] leviathanch. In addition, I'm also currently working on a pad cell generator, which dynamically layouts pad cells from a parametric meta design based on design rules provided [2025-08-23 1:53 p.m.] leviathanch. first however, we need to make the DRC violations and shorts go away [2025-08-23 2:01 p.m.] leviathanch. I wrote some text on our wiki page and built a Docker container with all the tools needed for getting started, even klayout should work (still some issues with IHP tho) https://wiki.libresilicon.com/index.php?title=StdCellLib {Embed} https://wiki.libresilicon.com/index.php?title=StdCellLib Index.php [2025-08-23 2:01 p.m.] leviathanch. I'd be very happy about support, because right now I'm basically a one man show [2025-08-23 2:03 p.m.] leviathanch. My own 1 micron process from Hong Kong currently refuses to route, IHP and SKY130 still produce short circuits which makes CharLib fail characterizing the cells https://gitlab.libresilicon.com/generator-tools/standard-cell-generator/-/pipelines/148 {Embed} https://gitlab.libresilicon.com/generator-tools/standard-cell-generator/-/pipelines/148 Pipeline · Generator tools / Standard Cell Generator · GitLab GitLab Community Edition 2025-08_media/twitter_card-570ddb06edf56a2312253c5872489-FA048.jpg [2025-08-23 4:17 p.m.] tholin I have a minor question. Has it become any easier to use a custom SCL in LibreLane? Doing so in OpenLane requires me to hack the PDK install, merging my SCL in and editing some config files to get it to recognize and even so I still need some hacks in the flow configuration too. I know this approach works with LibreLane too, I did it during a TinyTapeout experimental shuttle and my sky130 SCL, but I wonder if there is a better way by now. [2025-08-23 4:17 p.m.] tholin Can I just tell LibreLane "there is a separate SCL at this path, please include it"? [2025-08-23 4:42 p.m.] 246tnt If you couldn't with OL2, it's unlikely you can with LL. [2025-08-23 4:42 p.m.] tholin Talking about OL1 [2025-08-23 4:43 p.m.] tholin TT did use OL2 (or LL? I forgot), but I kinda just went with my hacky approach because I was pressed for time and knew it would work, at least [2025-08-23 4:48 p.m.] 246tnt I'm not sure. You could try to just override all the PDK SCL relative config options in your config ... [2025-08-23 4:49 p.m.] 246tnt All the stuff normally set in `config.tcl` and `$(SCL)/config.tcl` that you need to change, override those in your project config. [2025-08-23 4:50 p.m.] tholin That could work. Depends on if the project config takes precedence over the PDK configs. [2025-08-23 4:54 p.m.] 246tnt Yes, it should, I override defaults all the time. [2025-08-23 5:38 p.m.] mithro_ @Tholin - It might be worth chatting with donn on https://matrix.to/#/#librelane:fossi-chat.org {Embed} https://matrix.to/ Matrix - Decentralised and secure communication You're invited to talk on Matrix. If you don't already have a client this link will help you pick one, and join the conversation. If you already have one, this link will help you join the conversation 2025-08_media/matrix-logo-56B2E.png [2025-08-24 11:29 p.m.] tholin Okay, I’m still not done, BUT this has the same size as a caravel die and is pad-out compatible! Of course, without a mgmt controller, there is 5 more GPIOs. {Attachments} 2025-08_media/image-66242.png [2025-08-24 11:30 p.m.] tholin That took all weekend to get to work, even with htamas’ POC repo as a starting point. {Reactions} ❤️ [2025-08-24 11:37 p.m.] tholin Issues: - I’m pretty sure power isn’t connected - the several thousand warnings in the log about unconnected vss and vdd nets imply as such - the SL, CS, PD and PU pins on the bidir IO pads are tied to constant values. Not sure what to do with them. Forward to user project area? Tie to constants according to a user config file? Feedback on this is appreciated. - No SDC files to define delays introduced by IO pads - top-level STA is therefore questionable - Needs some Makefile magic to be more user-friendly of a setup [2025-08-24 11:37 p.m.] tholin I need to go for today, but I will work on this more tomorrow and create a repo. [2025-08-25 6:29 a.m.] mole99 Great work! But as mentioned earlier, we will most likely use new pad positions for Tiny Tapeout, which will become the new standard pad ring. Yeah, I also need to look into power connections. @htamas I noticed that you have some `CONNECT_POWER_PADS` defines in your code. Have you managed to get your padring to connect automatically to the core PDN? [2025-08-25 6:31 a.m.] mole99 @tnt One thing to consider for the future when I/O cells with different widths are a thing: Do we distribute the positions of the bondpads evenly, or do we make sure the distance between the I/O cells is evenly distributed? Currently, because all cells have the same width, both is the case. (Might not be that relevant for TT, but I would like to make the LibreLane padring step future-proof.) I would go for the latter. With the first approach there is the issue that you can't go as tight because a larger cell might already be touching its neighbours while the other cells still have space. If there are cells with two bondpads, such as for LVDS, it becomes difficult to ensure the same distance between all the bondpads anyways. [2025-08-25 9:35 a.m.] tholin What is the point of having the IE (Input Enable) pin on the bidir IO cells? I thought it tri-states something, but it doesn’t. Seems to just force Y to zero. [2025-08-25 9:40 a.m.] 246tnt It probably prevents shoot through current if you maintain a mid-rail voltage at the input. [2025-08-25 9:44 a.m.] tholin Possibly [2025-08-25 9:44 a.m.] tholin I figured having OE and IE set at the same time might cause a conflict, but I don’t see how. [2025-08-25 10:14 a.m.] 246tnt Yeah, the doc says that's invalid, but I also didn't really see what problem it could cause ... [2025-08-25 10:30 a.m.] tholin If you check my reverse engineered schematics, you’ll see that it makes no difference to a pin set to output whether IE is also set or not. [2025-08-25 10:39 a.m.] 246tnt Yes, that's what I concluded from the spice models too [2025-08-25 11:26 a.m.] tholin But I think, for the sake of completeness, I will wire the IEs to the user project area on my little setup too. [2025-08-25 1:11 p.m.] tholin @htamas I see the "GeneratePDN" step is still enabled in your top-level flow, even though it won’t actually do anything. Is there any reason for this? I had to disable it in my project because it suddenly started throwing errors for seemingly no reason. {Attachments} 2025-08_media/image-CA205.png [2025-08-25 3:00 p.m.] tholin Power routing is still an issue. I checked how they did it in caravel and its...odd. [2025-08-25 3:01 p.m.] tholin There is a macro in the hierarchy called "caravel_power_routing" that just contains short bridges on Metal3 that connect between the power rails in the pad ring, and the PDN of caravel_core. [2025-08-25 3:02 p.m.] tholin I would like to have a general-purpose solution rather than doing that part manually, so I guess its time to write a custom step? [2025-08-25 3:20 p.m.] tholin To visualize: The VDD and VSS IO cells have just a little bit of overhang on the Metal2 layer for all power rails, which is where caravel_power_routing latches on to and bridges to a PDN’s ring further to the right. {Attachments} 2025-08_media/image-D061C.png [2025-08-25 3:24 p.m.] 246tnt AFAIU `pdngen` should be capable of extending straps to the IO power rings but I'm not sure how to set that up. [2025-08-25 3:26 p.m.] 246tnt Ah but here it's some pad kind of thing. I know for caravel sky130 I did write a custom step for that. [2025-08-25 4:05 p.m.] tholin In any case, here is what I have so far: [2025-08-25 4:05 p.m.] tholin https://github.com/AvalonSemiconductors/ll_gf180_full_chip {Embed} https://github.com/AvalonSemiconductors/ll_gf180_full_chip GitHub - AvalonSemiconductors/ll_gf180_full_chip: Example of full c... Example of full chip with custom padring on gf180mcu using LibreLane - AvalonSemiconductors/ll_gf180_full_chip 2025-08_media/ll_gf180_full_chip-AD40B [2025-08-25 4:05 p.m.] tholin You can open it in the (latest!) iic-osic-tools and do `make user_project_example`, `make user_project_wrapper`, `make chip` [2025-08-25 4:06 p.m.] tholin Trying to emulate the efabless naming conventions a little bit. [2025-08-25 4:07 p.m.] tholin The only thing that’s missing is the power connections to the top-level PDN in `chip` [2025-08-25 10:49 p.m.] tholin Yeah, I believe I have to ask for help with the power connection problem. I’m not sure what the best approach would be here. Making hookups to the rails in the padring is also an option. [2025-08-26 8:38 p.m.] tholin I decided to just cheat a little bit. Made custom VDD/VSS IO cells that are actually just copies of the PDK cells, but I gave them tails like this. {Attachments} 2025-08_media/image-106BB.png [2025-08-26 8:38 p.m.] tholin I actually need to make them longer, they don’t quite reach the ring of the PDN. [2025-08-26 8:39 p.m.] tholin Literally called `gf180mcu_fd_io__dvdd_tail` because I’m not very creative. [2025-08-26 11:11 p.m.] tholin Okay, can’t get it to connect yet, but almost there. {Attachments} 2025-08_media/image-2FD02.png [2025-08-26 11:29 p.m.] tholin PDN won’t lock on to these and drop down vias. I’ll figure this out tomorrow. [2025-08-27 1:18 p.m.] mole99 {Attachments} 2025-08_media/Bildschirmfoto_vom_2025-08-27_14-51-07-8BA84.png [2025-08-27 1:18 p.m.] mole99 I managed to persuade pdngen to connect to the default I/O power/ground cells. [2025-08-27 1:30 p.m.] tholin I got it figured out may way too! {Attachments} 2025-08_media/image-52C2F.png [2025-08-27 7:01 p.m.] tholin Alright! Done! I even included a basic setup with cocotb for RTL and GL verification. https://github.com/AvalonSemiconductors/ll_gf180_full_chip [2025-08-27 7:03 p.m.] tholin {Attachments} 2025-08_media/image-270AD.png {Reactions} blobclap [2025-08-27 7:16 p.m.] tholin Only remaining issue is that LVS fails simply because the vsscore and vddcore nets in one circuit have a random number added to the end of their names? [2025-08-27 7:16 p.m.] tholin Weird [2025-08-27 9:15 p.m.] tholin 24,875 magic DRC errors :flop: [2025-08-27 9:24 p.m.] tholin Right, I remember this [2025-08-27 9:24 p.m.] tholin When I was reverse-engineering that IO cell, I saw that it had tons of DRC errors. [2025-08-27 9:25 p.m.] tholin The IO cells in the PDK are just....like this. They have tons of DRC errors. [2025-08-29 1:12 p.m.] tholin Doesn’t have much at the moment, but this is where I will upload all the extra standard cells I’m making: https://github.com/AvalonSemiconductors/gf180mcu_extra_cells [2025-08-30 4:57 p.m.] tholin Working on the multi-bit DFF now. I assume the point of that is area savings by making multiple DFFs share the same clock inverters, not just because of the reduced area from less inverters, but also because it simplifies the clock tree. [2025-08-30 5:26 p.m.] mole99 Nice, looking forward to it! [2025-08-30 5:27 p.m.] mole99 Do you know whether the I/O cells are violating the rules or whether the DRC deck is incomplete? [2025-08-30 5:45 p.m.] tholin I've been trying to put together 3.3V compatible IO cells by simply modifying the existing ones. And so I can say that, yeah, there are actual DRC errors in there that I keep having to fix. [2025-08-30 5:46 p.m.] tholin For instance, the pad driver macro on the 24t bidir IO cell has minimum width violations on resistive ndiff and pdiff regions. [2025-08-30 5:56 p.m.] mole99 That is interesting. I wonder how Efabless did their tapeouts then. Maybe these rules only apply to the core area? Or GF waived the DRC errors on the I/O cells? I'll have to ask Tim. [2025-08-30 5:59 p.m.] _saltypretzel Maybe since the pad frame was the same for each tapeout, all the chips would have the same drc errors in the padring [2025-08-30 6:01 p.m.] _saltypretzel I don’t recall having drc errors in the pad ring at least when I ran drc on magic. Of course, when they submit to fab, they maybe run their own closed source calibre deck on it first. [2025-08-30 6:57 p.m.] mole99 Yes, the same padring was used for all designs on GFMPW0/1 afaik. Did you submit a design to one of the shuttles? You probably only ran DRC on the `user_project_wrapper`, which was later integrated with the padring. [2025-08-31 8:32 p.m.] rtimothyedwards_19428 As far as I recall from the tapeouts, we got GF to waive all the errors that were inside their own cells. But it has been a long time since we did those tapeouts, and I have forgotten all the details. Reading other tools' GDS into magic is always a struggle, and what you see is not necessarily what you get. I'm running DRC on the Caravel GF version chip_io padframe now to try to refresh my memory. [2025-08-31 8:36 p.m.] rtimothyedwards_19428 A review of the padframe suggests that most errors are the usual struggle to read in layers like DUALGATE that may exist outside the cell with the diffusion that it affects, which is the sort of thing that magic does not deal with very well. Failure to see DUALGATE in the right cell then ends up triggering errors about different voltage gates in the same well. But I have yet to see anything that is obviously a real error. [2025-08-31 9:59 p.m.] tholin My conclusion as well. All errors to do with clearance and sizing are not technically impossible, quite clearly so if you look at all the working GFMPW chips. [2025-08-31 10:00 p.m.] tholin Can we expect a similar waiver from GF again? Otherwise, I am 100% down to sit down and spend a few days editing the IO cells to be DRC clean. ============================================================== Exported 162 message(s) ==============================================================